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Bruce E. Lavigne, Paul T. Cbngdoh, 
and Mark Gooch 
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Declaration by Inventors under 37 C.F.R. L131 

1. The persons making this declaration are the invenipra o f the above-referenced 
patent application. 

2. TThe following attached documents are submitted as evidence. 

Exhibit, A: Copy of PowerPoint presentation, dated January 23, 2002. 
Exhibit B: Copy of Bttf Miiroring Proposal, dated October 1, 2002, 
ExhibitC: Copy of IIP Invention Disclosure PDNO 20O3108S0-1, dated March 
24,2003. 

From Exhibit A, it can be seen that conception of the invention in the above- 
referenced application was made by at least January 23, 2002. 

4. The following facts are submitted to establish the diligence of the applicants from 
at least January 23, 2U02 until the filing of the aboverreferenced patent application. 

a. A proposal was developed for reducing the invention to practice in an 
actual product The proposal is shown in Exhibit B, dated October 1, 2002. 

,b. An invention disclosure was prepared, fo^ the 
invention. The invenUpn disclosure is shown in Exhibit C, dated y March 24, 2003. 

c: The ^oye-referenced patent application was filed on November 26, 2003. 
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5. As a person sigiiing belovVv 

I hereby declare that all statement made herein of my own knowledge are true; 
and jhat all statements niiadc on information and belief are believed to be triib; and further 
that these statements were made with the knowledge that willful false staiements and the 
likeso m^ by fine or imprisonment, or both, under Section IjOOl of Title; 

18 of the United States Code, and that such willful false statements ma^jeopardizethe 
yaiidity of the application or any patent issued thereon: 



Bmce-E/Lavigric 
^aul T. Congdon ^ 





Mark Gooch 



Date 
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Mirroring Overview 



1 



The concept behind mirroring is to replica te packets that someone is interested in to 
somewhere else where they can be captured and/or examined Packets that someone 
is interested in may be to/from a particular physical port (port mirroring), to/ from a 
particular ^XJSM pfiLAM mirroring), or based on other criteria (ACL mirroring, BMP 
mirrorihgi Hash entry mirroring), Replication may be local or remote, but a key 
Mature M to exfefcly implicate the mirrored packets on to the capturing/ examining 
equipment, including VLAN tags, TOS> TTL f etc, in addition, sometimes it is useful to 
manage the capturing/examining equipment over the same ethernet link, and other 
times it is desirable to only have mirrored traffic appear on the link to the 
capturing/examining equipment. 

This proposal extends the basic mirroring found in Alpha3 today by adding additional 
mirroring sources and additional' (remote) mirroring destinations. This not only brings 
us up to the rest of the industry, but surpasses it — one more BttF differentiator! 



The terms used both internally and industry-wide to describe mirroring today are 
very confusing and often ambiguous |mirror» monitor, snoop, probe* sniffer* SPAN* 
Roving Analysis; etc.), so we v& define 'the terms used in this proposal so at least it 
is clear what we are talking about here. These terms may or may not end up in 
general usage or visible to the custotrter. See the listed relevant subsection for a more 



thorough description. 
Mirroring 



The overall feature of replicating packets from 
some selected source(s) to a selected 
destination. 



Mirror Session 



One instance of mirroring configured on the 
switch. We propose a total of 4 possible 
sessions for BttF. each fully configurable and 
separate from each other. See section 4, i for 
more details. Many vendors support multiple 
mirror ports. Cisco currently supports 
between 1-4 sessions on various product 
lines, and uses the same term, session, as 
well. 



Local Mirroring 



The process of copying packets from enabled 
sources to a single configured port local to 
this switch. This is the only form of mirroring 
present on Aipha3. and on most networking 
gear. See section 3.1 for more details. Cisco 
refers to this as Switched Port ANalyzer 
(SPAN) or Port Snooping. 
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VLAN Remote Mirroring 



MAC Encapsulated Remote Mirror! rig 



IPv4 Encapsulated Remote Micmrtog 



Extended kf rro^log 



Mirror Source Fq«fe ($SPj 



Mirror Source VLAN pSV) 



The process of copying packets from enabled 
sources to a configured VLAN on this switch. 
Generally, the VLAN will be propagated to 
other switches which are members of this 
VLAN; See section 3.2 for more details, Cisco 
is the only other vendor who has this (that I 
could find), and; refers to this as Remote SPAN 
(RSPAN). 

The process of copying and encapsulating 
packets from enabled sources to a configured 
destination MM:/V%.M^/ef^Bp/^ protocol on 
this switch. Generally, the final destination of 
the destinatipr* MAC address is some other 
switch, allowing remote mirroring across a L2 
domain while iriaintalnlng the original VLAN 
tag and the ability to pass through older 
networking -gear, "See section 3,3 for more 
details No. other networking vendor has 
anything like this to my knowledge. 

The process of copying and encapsulating 
packets from enabled sources to a configured 
destination IP/MAC/ VLAN/L4 protocol on this 
switch- Generally, the final destination of the 
destination IPv4 address is s^rne other switch, 
allowing remote mirroring across a L3 domain 
white maintaining the original MAC^P/VLAN 
.tag. and the ability to pass through older 
$^itching^outln^ gear^ See section 3.4 for 
rriore details. No other networking vendor has 
anything like this to my knowledge. 

The process of copying packets from enabled 
sources in ah extended form (includes ISM) to 
a configured d^tination. This allows us to 
send packets to a Special Function Card 
based on things like output port, which the 
current copy logic does not permit* or to send 
extended packets to a (possibly remote] sniffer 
during debug. No other networking vendor has 
anything like this, to my knowledge. 

.A. port whose ingress {rx) or egress (tx) traffic 
(or both) is copied from in the mirroring 
operation. This is referred to as Port-based, 
mirroring (Cisco's PSPAi% See section 2,1 for 
more details, 

A VLAN whose ingress (rx) or egress (txj traffic 
(or both) is copied from in the mirronrig 
Operation. See section 2,2 for more details. 
This is referred to as VLAN-based mirroring 
(Cisco's VSPANK 
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Mirror Source MAC (MSM) 



Mirror Soiree IP (MSI) 



Mirror Source Subnet (MSS) 



Mirror Source ACL 



Mirror Dest Port (MDP) 



Mirror Dest VLAN (MDY) 



Mirror Dest MAC (MDM) 



A MAC address whose ingress (rx) or egress 
ftx): traffic (or both) is copied from in the 
mirroring operation. This is referred to as 
MAC -based mirroring (it comes from the L2 
hash table). See section 2,3 for more details; 
No other networking vendor has a counterpart 
that I know of, 

An IP address whose ingress (rx) or egress ftx) 
traffic (or both) is copied from in the mirroring 
operation. This is referred to as IP-based 
mirroring (it comes from the L3 hash table). 
Mote that this would apply to routed packets 
only; See section 2.4 for more details. No 
other networking vendor has a counterpart 
that I know of 

An IPv4 subnet address whose egress (tx) 
traffic is copied from in the mirroring 
operation. This is referred to as Subnet-based 
mirroring (it comes from the BMP table - and 
thus has no ingress variant). See section 
2.5 for more details. No other networking 
vendor has a counterpart that 1 know of. 

An ACL match whose traffic is copied from in 
the mirroring operation. This is referred to as 
ACLrbased mirroring (it comes from the ACL 
table - and thus is effectively both ingress and 
egress, depending on the ACL fields selected). 
See section 2.6 for more details. No other 
networking vendor has a counterpart that I 
know of. 

The port defined as the destination for Local 
Mirroring. All packets from the various 
enabled Mirror Source locations will be copied 
to this port. See section 3.1 for more details. 

The VLAN defined as the destination for VLAN 
Remote Mirroring. All packets from the 
various enabled Mirror Source: locations will 
be copied to this VLAN. See section 3.2 for 
more details 

The MAC address encapsulation defined as 
the destinatibn for MAC Encapsulated: Remote 
Mirroring. All packets from the various 
enabled Mirror Source locations will be copied 
to this MAC address by encapsulating them 
with either an 18~byte Ethernet 11 header 
consisting of DA/SA/VLAN/ETYPE/ 
RESERVED/EL AGS/TCI , or a 36-byte SNAP 



HP Company Confidential 



BttF Remote Mirroring Proposal — • 10/ 1/02 



-5- 



6- 



reyisicm 10 



Mirror Dest IP (MDI) 



Mirror Truncate Length 



Mirror E;xit Switch fMES) 



header consisting of DA/SA/VtAM/LEM/ 
LSAP/CTL/ORG/ETYPE/RESERVED/FLACS/ 
TCI See section 3.3 for more details. 

The IPv4 address encapsulation defined as the 
destination for IF Encapsulated Remote 
Mirroring, All packets from the various 
enabled Mirror Source locations will be copied 
to this IPv4 address by encapsulating them in 
a 36-byte header consisting of DA/SA/ 
VLAN/IPv4_HOR. See section 3.4 for more 
details. 

The maximum internal size of the mirrored 
packet. Two reasons to truncate are: t) to 
prevent oversize packets in the network when 
using Mirror Encapsulation, and 2) to lessen 
the network load by only mirroring the first 
portion of packets. This may be set to zero to 
never truncate. Since this is an internal size, 
it is con%ured ifi 1 8-byte blocks. The 
conversion from internal length to actual 
packet length is described in the BttF 
Architecture Interchip Interface Specifica lion. 
See section 4 2 for more details. 

Trie switch which is the exit point for a MAG 
or IP encapsulated remote mirror stream. This 
is determined by the DA lookup, which 
returns a ' p mirror_exit* bit in the ISH. At this 
point, the packet is decapsulated in hardware 
and sent out the destination port exactly as it 
appeared on entry to the mirror "tunnel". 
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Mirror So urces 2 

There are six types of sources for mirrored packets. Note that, some types can have 
ingress (rx) traffic enabled » some egress {tx) traffic enabled, and some both enabled .. 
Also note that in the current definition of BttJF, some types are not implementabie 
since we are short on bits in some lookup tabled In general. If more than one type of 
source is enabled for a particular mirror session, then traffic matching any of the 
configured types is mirrored (see the description in port and VLAN mirroring for the 
one exeeptiory to this rule) * 

2.1 Port- based Mirroring 

Port-based mirroririg allows Ingress (rx) and/or egress (tx) traffic on a port (network 
or CPU) to be copied to the mirror destination* Any numbler of source ports may be 
specified per mirror session, in any combination of rx, tx, or both. 



Note - The combihation df port-based mirroring with VLAN-based mirroring below 
may be configured as an OR operation (as in current AlphaiSj, or as an AMD 
operation, where in order to mirror a packet, it must belong both to a MSP 
and a MSV; This matches Cisco's * fitter* option. 



22 VLAN-based Mirroring 

VLAN-based mirroring allows ingress (rxj and/or egress (tx) traffic on a VLAN to be 
copied to the mirror destination One ¥LAN may be mirrored per mirror session, with 
either rx, tx, or both enabled. 



Note - The combination of port-based mirroring above with VLAN-based mirroring 
may be configured as an OR operation (as in current Alpha3} ? or as an AND 
operation, where in order to mirror a packet, it must belong both to a MSP 
and a MSV. This matches Cisco's "filter'* option. 



2.3 MAC-based Mirroring 

MAC-based mirrOrir*g allows ingress (rx) and/or egress (tx) traffic matching a MAC- 
V1D pair (an entry in the MAC hash tabl^ to be copied to the mirror destination. Any 
number of hash entries may be programmed per mirror session, in any combination 
of rx, tx, or both. 



implementation Note - Current SttF WAC hash amy definition, ft&s two bits set aside for tm function. - one 
used on We source lookup, one m&ddwih& destination lookup^ £ach^k has mapping to one of the- four 
mirror sessions, configured pet chip in the HPB Thus, we support any one mirror session for source and any one- 
mirror session for destination, with any number of nash entries able ip set these mirror session bits. 
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trnpfementamn mate ~ if trie Bizf box has touting enabled software should scan through the U hash and 
BMP tables for the egress MAC address in question as weft, since we don't do another dest MAC lookup 
onee we 've done a dest IP lookup, it /{ finds the egress MAC, it can set the minor bit m those taptes ajso^ 



2 4 IP-based Mirroring 

IP-based mirroring allows ingress (rx) and/or egress (tx) traffic matching an IP-VID 
pair (SA, flows) or IP address 0A) (an entry in the IP hash table) to be copied to the 
mirror destination., AfQf number of hash entries may be programmed per mirror 
session. In any combination of rx, tx, or both. 



implementation Note ~ Current BttF t$. h&£ft ioottup & only performed oh muted packets,, so bridged IP 
packets will not hit on. these entries, and: will, not be selected with- th& tya#,.of'minoriogr Aft® note tha t the 
source tP lookup, is not done unless security or some other feature is ena bled, and the destination IP- lookup 
is not done # th^ BMP lookup hit and" was not listed as- having < a more, sp ecific route, 



imptemeniatipn Note - Current Bit? IP hash entry, definition has two bits set. aside for this function - one used 
on the mume lookup, one used, pn the de$$oai$#i. hokpp., igafcfc #t 'f^^^f^f^'^- on& df. c£e- fmx:. mirror 
'sessions, configured per chip, in the-HPP Thus, we support any one mirror session for source and any one mirror 
■ses^dnhr d&stinaiiom: wftfr any number brmmeH&ies a&jmo set r^e^ fl^rsd^nTb^v- ' 



2.5 Subnet-basedM 

Subnet-based mirroring aJJows egress (tx) traffic roateMng art W mbmtt address (an 
entry in the BMP table) to be copied to the mirror destination. Any number of table 
entries may be programmed per mirror session. 

implementation: Note -..Current Bit? BMP. table, entry. "deHnitian tea sln0eiit.set aside for . this function,, with 
a mapping tp one o?the{fbut : mjffpr sessions mnfigjLire.4 p'&r'Chi'^ me ^PP Thus; we support any one minor 
session, wit$ any number of BMP entries abie to set the mirror, session oft 



2, 6 ACL-fyase® ^Mirroring 

ACLbased mirroring allows traffic matching an ACL entry (ternary match on I? JDK 
1PJSA. TCrP/liDF source & destinatksri port numbers, TCP Syn & Aek bits, & physical 
ingress port) to be copied to the mirror destination. Any number of table entries may 
be programmed per mirror session Since both source (ingress) and destination 
(egress) IP addresses are available in the ternary CAW. we can support rx, tx. or both 
on each entry. This form of mirroring is more powerful than; the above two forms, in 
that with the ternary CAM , we can ^rbrm Ipbased mirroring* Subnets based 
mirroring^ or flow- based mirjraring, and match br* fields not present in 
any of the other forms. Also, these lookups are done for both bridged and; routed IP 
packets. The downside is table space — first off r there are only L.5K CAM entries 
today, and secondly,, configuring mirroring with other ACLs m the system will require 
some form of ACL eom|$lef or operator intervention. 
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Mirmx- Destinations 3 

There are four types of destinations for mirrored packets. The destination types are 
mutually exclusive — only one type of destination may be configured at a time on 
each mirror session. Any destination type may be configured as normal or extended, 
lossy or lossless, throttlabJe or not. forced tagged/ untagged; and can override 
out„queue 

3. 1 Local Mirroring 

Local mirronng sends the mirrored traffic: to a specific port (the Mirror Destination 
Port, MDPy on this switch. This is the most basic form of mirroring, and is the only 
form of ml nroring present on A! phaB switches. 



Note - Following Cisco's lead, we probably want to allow software to optionally disable 
i^rhmg| and o^pnaiiy not forward ingress traffic from the MOP. .'FW BttF, 
this can be accomplished by setting the port NWS>T state to "not^a^member*. 



im$ementmkm time - Packet m^ng 'my hoi exacc/y mmctirtfie source tor local Mirroring, due to.- son 
.e^^hm^on^He^encm. registers), if- this is an . tmie, one must use one of the more advanced 

Encapsulated Remote Mkj : qrlng : meifiopt 



tmpiemem&mn-Nbte - The MBP-ma^noi be-a member o£a :me$H forimvtitt break the messing code. 



32 VLAN Remote Mirroring 

VLAN remote mirroring floods the mirrored traffic to a specific VLAN (the Mirror 
Destinatipri VLAN, MDV) on this switch. "Th is ;; VL&N can be configured oh multiple 
switches to propagate (flood) mirrored traffic in a layer 2 domain to a sniffer on 
another ^itfi^: ; S4iaGC- mirrored -packets are copied to the MDV; the original VLAN 
tag is lost with this type of mirroring This is how €isco r s ESP AN works. 



Note - Again, we probably want to optionally disable learning on this VLAN. For BttF, 
this can be accomplished by setting the VID as illegaL 



implememauQn. Nota - The- MOV m&% not contain, any ports wfttch are a member- of a -mesh, for this will 
break ^,/n.0^ng.c;^^. _ . 
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3. 3 MA C Encapsulated Remote Mirroring 

MAC Encapsulated remote mirroring encapsulates the mirrored traffic by adding 
either an 1 8-byte Ethernet: TF header or a 36-byte SNAP header to t he beginning of 
every packet, and forwarding the resulting packet out using a software configured 
logical port. This allows mirrored packets to traverse any number of switches 
(belonging to any vendor) in a layer 2 domain before being deeapsulated in hardware 
at the destination switch (which must be a BttF product appropriately configured) 
and forwarded out a sniffer port. The format of the 1B> byte Ethernet II header is: 



! 

destin 


i 1 1 

ationLmac^addr 

i ! ! 


* 


j 1 r 

'ce_f|iac^addr| 


etjjpe 


rsvel 




TCI 



| Figure 3-1 MAC Ethernet II Encapsulated Remote Mirroring Header 

The format of the 36 -byte SNAP header is: 



i 

destin 

i 


i 

*tiori_ma 


{ 




source^rnac_iddr 

1 ! 1 






: 

LS 


AP 


CTL 


DRC 


o£c 

(cojht) 


1 

I etype 

i 








f rJserved ! 




l 

r . I 




flags 





Figure 3-2 H0lC : $i^A!P'''Wm^pSfaf9%eA Remote Mirroring Header 



Software writes all 18 or 36 bytes of. this header, along with a logical port register and 
some override bits {force tag/untag, extended, outjaueue & override, throttlabie, 
mclassjto, lossless} 

During packet encapsulation, the 16 bit TCI field (CGS/iWVID) which software 
writes is moved into the SEND header, where it becomes part of the outgoing VLAN 
tag (if tagged), the mirrored packet s TCI field is moved: into the header field, so that 
on decapsulation, it can be properly placed in the restored packet's VLAN tag The 
upper bit of the flags field (0x80) is written by the ASIC into the header indicating 
whether the restored packet should be tagged or not. this operation essentially 
preserves the ^rigteal VLAN tag of the packet , so we exactly r%>licate the packet to the 
sniffer port. The rest of the flags Held is currently reserved for use by the ASIC. The 
determination, of whether the restored packet should be tagged is as follows: for 
input, If the packet arrived; tagged, it should be tagged; for output, there will be one 
set of PPVID registers which software can program in the; same way as an output port 
— if the packet was egress mirrored and it matches one of the PPVID registers, it will 
&$ uotaggedi otherwise tagged. If there is a conflict (i.e. a packet is mirrored on 
ingress and egress};, tagging wins. 

For the SNAP encapsulated packets, the length field is computed based on the (hew) 
xfer_ 18 value and aclj-bytes. It this length is/grea ter than a software configured value, 
then the length field is not overwritten by the ASIC This allows software to place the 
jumbo value 0x8870 in the length portion of the encapsulation, and then decide how 
large a packet must be before the 0*8870 is used. Setting the length compare to zero 
forces the software's configured length field on all packets, setting the length compare 
to a number larger than the max size packet (say, 32K) forces the length to be always 
computed (even if it generates values which could be construed as an ethertype),. and 
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setting the length to some Intermediate value (sa#,: 11518'.. the default value) uses the 
software configured length if the packet becomes larger than a normal etheraet 
frame. 

The resulting encapsulated packet ts then ser# to the configu red logical port: 

Mote that the resulting packet nftay be larger than the^m^imum allowed 'Sim on some 
links between t&e source and the final destination. To address this, we allow software 
to configure a Mirror Truncate Length (see section 4.2 ) if it so desires. 

It Is expected that some higher ^la#er software; ~- either via user cpnRgu ration or via 
communication with the dfecapsulattng s^vitch' — i& determining the correct values of 
MA£ addresses, etype. '*tiC% etc, to put in the header: 



Wtmsolv^ r- The etypeffeld; heeds to Me chosen with cai&- j&^&p^^p 

conflict with- exist ingr protocols* Does Hp own one, or are t|jey even availably? 

Decapsulation is also handled by the ASM; if the switch detects that: it is the Mirror 
Exit? Switch (IviESK then the IS^byte {Ethernet D) or 36vbyte (SAP/SNAP) 
encapsulation is stripped* and the VLAlsi tag is restored fr dm the TGfeflag^ portion of 
the encapsulation* 

Original Mirrored Packet 



DA 


m ■ 




Ten 



CRC 



Encapsutated Mirrored Packet 



Decapsuiated MirrbredoPacket 




| Figure dfdt* MAC Ethernet, II EhjG^psulated Itempte Mir^ 



Original Mirrored Packet 



| da [• sa \yiM^^ im^m I 




Decapsuiated Mirrored Packet 

j PA f SA [ Vl^f[^j payload [ CRC 

| Figure 3*4 iVi&C SNAP Encapsulated Remote Mirroring Packet Formatting 



EitF Remote Mirroring Proposal ^lQ*i/Q2 



. It ., 



revision 1.0 



3. 4 IPv4 EmapsuimedReirmteM 

IPv4 Encapsulated remote mirroring encapsulates the mirrored traffic by adding a 38- 
byte IPv4 header to the beginning of every packet, and. forwarding the resulting 
packet out using a software configured logical port, Th is allows mirrored packets to 
traverse any number of switches or routers {belongings to any vendor) in a layer 3 
domain before being deeapsulated in hardware and forwarded out a sniffer port. The 
format of the header is: 
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Figure 3-5 IP Encapsulated Remote Mirroring Header 

Software writes all 36- bytfes -.-cfp IMp Iteader, &icng with a logical port register and some 
override bits (force tag/untag, extended, outuqueue & override; throttlable, reclass^to, 
lossless). 

During packet enc^psuiatiotiv the 18-bit TCI meld (COS/TR/VID) which, software 
writes is moved into the SEND header, where it r^cqmes part of the outgoing VLAN 
tag. The mirrored packets TCI field MS moved into the header field, so that on de- 
encapsulationv it can be-prpperly- placed' ' in ; *the' restored packet's VLAN tag The upper 
bit of the identificauon field (OxSOQQ) is written by the ASIC into the header indicating 
whether the restored packet should be tagged or not. This operation essentially 
preserves the original k$M^'-&fj(- of the (packet so we exactly: replicate the packet to the 
sniffer por*; Tft& second bit of "the identMcati&n fteld $$x4S&t)| is written by , tip ASIC; 
to indicate which FD is sending this packet, and is used along with the rest of the 
identifi<^ion field write numbers by the A^IC; to uniquely identify 

this packet across the network. Note that software ought to set the "dpn t fragment' , 
bit - Hags bit 0x8%, because the Mirror Exit Switch fi^ESI will NOT be able to 
correctly re-assemble fragments and send the original packet to the sniffer. The total 
length and checksum fields aw aJso prdperly computed by the ASIC. The 
dete^mip.|%foii of whether thfe restored packet should be tagged is as follows: for 
input, if the packet arrived tagged, it should be tagged; for output, there will be one 
set of PFVTD registers which software can program in the same way as an output port 
— tf the packet v^as egress mlrrdr^d atid it rha^hes one bf the PPVID registers, it will 
be untagged, otherwise tagged If there is a conflict fl-S- a packet is mirrored on 
ingress and egress), taking wins. 

The resulting encapsultated packet is then sent to the configured logical port. 

Mote that the resulting packet may be larger than the maximum allowed size on some 
links between the source and; the final destination . To address this^ 
to configure a ivtopr Truncate Length {see section 4 2f )' if it so desires 

It is expected that some higher-layer software either via user configuratipn or via 
communication with the decapsu^ is determining- the correct values of 

MAC addresses, TCI, IP Addresses, protocol etc. to put in the header. 
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Unresolved Issue - the proto field needs to be chosen with care so as not to 
conflict with existing, protocols; Does HP own one, or are they even available? 



Unresolved Issue - How does this work in the presence of VPN's or other 
security features? Do these things need to be disabled when IPv4 remote 
mirroring? 



Note - The next- hop MAC address (da^mac) needs to be updated by software if 
routing updates cause the mapping from dest~IP to desfc-MAC to chan^ 

Decapsulation- is also handled by the ASIC; if the switch detects that it is the Mirror 
Exit Switch (MES), then the 36 -byte IPv4 (for hw^ctbi pkts) encapsulation is stripped, 
and the VLAN tag is restored from the TCI/Rags portion of the ehcapsuiatidh 



Original Mirrored Packet 



| PA [ $A | VUVN|^| payload [ CRC | 




tjecapsulated Mirrored Packet 



Encapsulated Mirrored Packet 



| dA | SA [ VLAN l ( er| payload JgjRG, j 




I 



Figure 3-6 IPv4 Encapsulated Remote Mirroring Packet iFormattihg 
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AjcMiti0ri& 4 

4.1 Mirror Sessions 

We propose four individual mirror sessions for ©ttE Each is independently 
configurable on both sou ree(s) and destination. 

4. 2 Packet Truncation 

We propose a set of Mirror Truncate length .ggjg|fie&t . -one ;per session. Setting these 
registers to zero disables truncation. The value of thfe feature is twofold: 

1. Mirrored packets that are encapsulated may grow beyond the maximum transfer 
size of siibseqtient links, arid thus may be dropped as being oversized unless they 
are feruncatedC 

2. For performahce reasons, it may be behetteial to mirror only the first porttort of all 
packets — thus, if a fuU^dupleJC link was sending line-rate packets with an average 
packet size of SOB bytes, we could rxuheate to 250 bytes and mirror both input and 
output on a lin k pf the same speed without dropping any packets. 

4. 3 Filtering based on da_type 

It may be useful to separately ehable/disabte mirroring of packets based on da.type. 
so that we only mirror unicast traffic, or multicast traffic, etc. 

4. 4 Forcing Best Effort On/Off 

Generally, forcing Best Effort mode on mirrored traffic will prevent head-of-line 
blocking issues — especially if the mirror iitik is overloaded with traffic, as would be 
the case when using a same-speed link to mirror both ingress and egress traffic, 

Mowever, it may be desirable. If the user knows the mirrored traffic is light but 
bursty, to disable Best Effort; and take the risk pf head-qf-line blocking in order to be 
assured that ail traffic is correctly mirrored to the sniffer. 

4 5 Mirroring CPU ports 

This should pretty much come for free in the current BttF architecture, but mirroring 
ingress/egress/both CPU packets may be useful. Probably want a configuration to 
understand CPtLmessage packets, to either mirror them or not (customers would 
NOT want them mirrored, we may want ONLY them mirrored). 
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Changes/Impacts per Module 5 

5. 1 Input Preprocessor (IPP) 

None 

5.2 HashPrePmcessoriHP^ 

t. Extra bit in L2 and L3 hash tables - "Mirror Exit'", copied to ISH 

2. Changes to learn & drop rules to support not learning or forwarding from 
MDP/MDV 

3. Extra "ingress mirror" bits in L2 and L3 hash tables - if there's room 

4. Configuration for port/vtah AND vs. 0R mirroring 

5.3 Chip LpokUp Engine (CL UE) 

t . Mirror logical port registers v override bits, per session 

2. Mirror destination t^pe registers per session 

3. Mirror da_type Rlter registers, per session 

5 4 MegaEngiiie (ME) 

None 

5. 5 Fabric Driver (FD) 

h Mirror Encapsulation RAM, pier session 

a. Mirror Truncate Length registers, override bits, per session 

3. BnGapsuiation /Decapsulation logic 

4. FPV1P registers (5) per" session to determine tagging 

5. Enhanced BEA logic (falls out of rec!ass_to updates) 

5. 6 Fa bric Recei ver (FP^ 

1 . Pass back "sent to MDP r bits in Buffer Replv 

2, Configuration for port/vlatv &NB- vs, 0R mirroring 
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Instructions: P) 
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le information contained in ihisdocurnentis COMPANY CONFIDENTIAL and may not be disclosed to others 
horization. Submit this disclosure: to the HP Legal Department as soon as possible. No patent protection is 
aient application is auihprized, prepared, and submitted to the Government 



Descriptive Title of invention: 

demote Mirroring of Network Traffic 



Name of Project: Back to the Future 



Product Name or Number; 

None defined yet 



Was a description of the invention published, or are you planning to publish? ff so, the date(s) and publicatiort(s): 

Yes ; planned for BttF product dbciHn&nfcation, published near MR, expected Ql '05 

Was a product including the invention announced, offered for sale, sold, or is such activity proposed? If so, the date(s) and 
location^): 

BttF products containing this invention: are expected to: MR worldwide in Q1'05 
Was the invention disclosed to anyone outside of HP, or will such disclosure occur? If so, the date(s) and narne(s): 

NO 

If any o1 the ab^ simikris 



Was the ihveryftonde^ please identify {lab bc^)k#, etc.) 

Yes: Remote Sort ,Moni,tor.ing.-ppt t: ;dated : Jaimary 23,, .2002, and 
BttF Remote Mixroririg Proposal - fnls/lisic/fe^^ 
dated October 1* 200-2 (attachM)i 



Was the invention built or tested? If so, the date: 

.In progress {"see MSC cbt* abcwej : 



Was this invention made under a government contmct? If so, the agency and contract number: 
no 



Description of Invention: Please preserve all reqords of the invention and attach additional pages for the following Each 
atifaKf^ the-lnvmtor^) $hdmtness(^ 

A. Prior solutions and their disadvantages (if available, attach copies of pr#uct literature, technical articles* patents, 
etc.). 

B. Problems solved by the invention. 

C. Advantages of the invention over what has been done before. 

D> Description of the construction and dperStton of the invention (include appropriate schematic, bloc*, & timing dia- 
yams; drawings; samples; graphs; flowcharts; computer listings; test results; etc.) 
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A. Prior solutions and their disadvantages 

Current mirroring solutions copy packets to an additional port of the switch. The disadvantage is thai the network analy- 
st device must be directly attached to the switch which needs monitoring, li miting the usefulness of this technology. 

In Cisco's fitSMN technology, the packet may be mirrored to a specific VLAN. This allows the analysis device to be on 
a different switch* but it soli must be within the layer 2 domain of the traffic which is to be monitored, andin addition, the 
packet has now been modified (by adding/replacing the VLAN tag) from its original format These two restrictions limit 
the usefulness of RSPAR 

Other network protocols may encapsulate packets, generally in software, to tunnel them across an arbitrary network 
(Generic Routing Ehcapsulation, GRE, for example). To date, this has hot been coupled in hardware with mirroring traf- 
fic, plus even existing protocols such as GRE don't maintain complete feyer 2 information such as the original VLAN 
tag, making exact replication: of monitored traffic unattainable at a remote location. 

Additionally, the choice of which packets to monitor is rudimentary i n today's products. One can choose to mirror traffic 
which is ingress or egress on a port or a V LAN, that is all. 

B. Problems solved by the invention 

This remote mirroring technology allows exact copies of packets monitored from one switch to be encapsulated at line 
rate and ^ansmitted through a general t&twqrk and thejn .cte^pstilated ahdsent out at a geographically remote site. 
Also, the choice of which ^ckefe^o^mo^nitot is Enhanced by adding Access Control List (ACL) and hash lookups of the 
packets, 

C> Advantages of the invention over what has been done before 

As stated in the above two sections, today's solation&do not allow fully reimote network troubleshootings due to distance 
limitations, disruption of true packet formatv lack of full media speed support, or a combination of these. This invention 
solves all ofthese problems, plus adds additional choices in hpw to select which packets to monitor as well; 

D. Description of the construction and operation of the invention 

See enclosed £V BttF Remote Mirroring Proposal" 
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